A database transaction is a unit of work performed by a database management system (DBMS) or other application associated with a database. Transactions are generally performed using an “all-or-nothing” approach, meaning that all work units associated with a transaction must complete or none must complete. A “commit coordinator” built into a DBMS or application may ensure that a transaction completes in its entirety or not at all.
For example, consider a financial transaction where an application performs several steps using an “all-or-nothing” approach. In particular, the application transfers funds from a checking account to a savings account using the following steps (listed in pseudo code):                begin transaction                    debit checking account            credit savings account            update history log                        commit transactionAll of the three steps must complete, or none must complete. Otherwise, data integrity will be lost. Because the steps within a transaction are processed as a whole, a transaction may be defined as an indivisible unit of work.        
A transaction may terminate in one of two different ways, namely with a COMMIT or a ROLLBACK statement. When a transaction ends with a COMMIT statement (hereinafter referred to as a “COMMIT”), data modifications specified by the transaction are made permanent in the database. If, on the other hand, one or more data modifications in the transaction fail, a ROLLBACK statement (hereinafter referred to as a “ROLLBACK”) may be used to undo the effects of all statements in the transaction. For example, if a disk drive were to crash during the “credit savings account” step listed above, a ROLLBACK statement could be executed in order to undo the data modifications made by the “debit checking account” statement. Although the transaction failed, data integrity would remain intact to keep the accounts balanced.
Unfortunately, an application may perform certain actions or cause certain actions to occur that fall outside of the application's normal “commit coordination.” For example, consider an application that invokes, as part of a transaction, a service provider to perform some action, such as store a large image file in a file system. The service provider and file system may have no knowledge of the transaction. Thus, the actions performed by the service provider may fall outside the application's “commit coordination.” In other words, the application may be unable to reverse actions performed by the service provider if the application ultimately performs a ROLLBACK. Likewise, the service provider may have no knowledge of the ROLLBACK and thus will also be unable to take actions to reverse the action. Using the above example, such a scenario may lead to orphaned files in the file system that were not reversed (i.e., deleted from the file system) in response to a ROLLBACK.
In view of the foregoing, what is needed is an apparatus and method to reverse actions performed by a service provider or other entity acting outside an application's normal commit coordination. Such an apparatus and method would ideally be implemented without the need to modify the application and/or DBMS. Such an apparatus and method would also ideally leverage existing functionality in the application and/or DBMS.